When a patient seeks healthcare services from a healthcare provider, the provider may request information from a payer (e.g., insurance company) to determine if the patient is eligible to receive benefits for healthcare services; and if the patient is eligible, other benefit and eligibility information such as benefit amounts, co-insurance, co-pays, deductibles, exclusions, and limitations related to a specific procedure may be provided. The request for information may be sent as an eligibility request, for example, a 270 request or transaction. A payer may communicate eligibility benefit information associated with a subscriber or dependent in a response, for example, a 271 response or reply.
The eligibility request and response may be required to meet transaction processing standards. For example, eligibility transactions may be sent in an X12 syntax format and may be coded and structured according to standards established by the Secretary of Health and Human Services (HHS) as required by the Health Insurance Portability and Accountability Act of 1996 (HIPAA). As is known in the art, HIPAA includes provisions for administrative simplification and support electronic exchange of administrative and financial healthcare transactions primarily between healthcare providers and plans. As should be appreciated, embodiments may be utilized with other formats, structures, and syntaxes according to changes in healthcare laws. For example, a 270 eligibility request may be replaced by an eligibility request of another format and utilizing an alternate syntax. A 271 response may be replaced by an eligibility response of another format and utilizing an alternate syntax.
Prior to Jan. 1, 2012, the transaction standard in use was the X12 version 4010A1. The 4010 transaction standards drove billing, reimbursement, and administrative functions. As is known in the art, the 4010 standards provided a one-size-fits-all type of eligibility response driven by a service type code (STC) 30 (Health Benefit Plan Coverage) in the 270 eligibility request. For example, payers would sometimes return a large list of service type codes (i.e., benefits) that were covered in a patient's health plan, and sometimes even service type codes that were not covered. In addition, some payers would include a patient's portion of financial responsibility (e.g., co-payment, deductible amount, co-insurance, etc.) at the plan and sometimes at the benefit level. A challenge to providers receiving this type of response was sifting through the large amount of data returned by the payer to locate the benefits that were relevant to the provider and their patient. The challenge was sometimes compounded by some payers returning free form text forcing human interpretation rather than a systematic approach to reviewing a response.
To help provide improvements to electronic data interchange (EDI) transactions including greater clarity in provider loops and national provider identifier (NPI) instructions, reduced ambiguity among common data elements, and elimination of unnecessary or redundant data elements, the 5010 transaction standard was developed. Therefore, HIPAA X12 version 5010 became the new set of standards regulating the electronic transmission of specific health care transactions including eligibility, claim status, referrals, claims, and remittances.
A first phase of operating rules requirements for the 5010 version of the 270/271 transaction was adopted, the 5010 version outlining a set of benefit groupings based on ten high level category service type codes that payers can support. For example, a hospital may send a 270 request with an STC 47 (i.e., service type code for a hospital); and accordingly, the payer would reply with relevant benefits for a hospital and suppress benefits only relating to the other nine high level service type codes. This is referred to as a component level request and response.
Subsequently, a second phase of operating rules was adopted, adding an additional thirty-six STCs to which payers would have to respond. This is referred to as an explicit STC request and response. The explicit STC request and response is more focused than the component level request and response.
As payers moved from the 4010 standards to the 5010 standards for the 270/271, many of them adopted the support for the component level request and response and thus removed many of the details that were sent in a 4010 generic response. The details were returned when a component level request or an explicit STC request was received.
As providers migrated from 4010 to 5010 and the payers they processed eligibility transactions with also migrated from 4010 to 5010, providers saw the level of details change in their responses to a generic STC 30 inquiry. For some health plans, a greater amount of details came back, particularly for payers that sent a bare minimum 4010 response. For other payers, less detail was provided in the generic response as those details were moved to either a component level response or an explicit STC response.
Many providers may not be aware of the component level or explicit STC request and response capabilities that the payers implemented, and merely perceived this as a reduction in the level of information that was being returned. Additionally, many Health Information System vendors only allow for the submission of a STC 30. The result has been that those providers may see a lot less information in their 271 eligibility responses. In some cases, this may result in a perceived degradation of service (even if the missing information was irrelevant to them); however, in some cases, some detail in the mountain of data returned in a generic STC 30 response had value to the provider. The trend will likely continue as payers implement the ACA Operating Rules which require them to offer component and explicit service type code requests.
It is with respect to this and other considerations the present invention has been made.